Authentication and Authorization

Learn about authentication and authorization and their respective protocols.

What are authentication and authorization?#

To fulfill our security goals, the API needs to be able to differentiate users in our system and potentially fend off nefarious users. Let’s take the example of a banking API. It would be detrimental if we couldn't verify the identity of the individual users utilizing our API, and because of the inability to do so, an imposter gains access to another user’s account and the assets within. Also, not all service users are alike—some might be individual users, while others might belong to a large organization. The authorization mechanism manages what each user is permitted to do based on their user category, such as having the ability to call different functions or make specific number of API calls per day. Therefore, to implement the methods above, authentication and authorization become essential to implementing the security goals we defined earlier in this chapter.

Authentication refers to the procedure through which our API verifies who the user is. Typically, applications fulfill this by implementing a login system utilizing usernames and passwords for verification. There are other techniques for authenticating users in the API paradigm that we’ll explore in this lesson.

Authorization is controlling what the user has access to. This is when applications verify whether the user is even allowed to call the request they are making. For example, we may be authorized to view a Google Doc but not edit it.

svg viewer

Let's begin by defining some common authentication protocols prevalent in the API landscape, after which we'll expand on the frameworks that combine and utilize these protocols to implement both authentication and authorization.

Authentication and authorization mechanisms#

There are several mechanisms we can explore in this section, so let's take a look at those prevalent in today's industry. We'll begin with one that's largely regarded as the simplest, HTTP basic authentication.

HTTP basic authentication#

HTTP basic authentication is a rudimentary scheme that verifies a client through username and password authentication. It encodes the user's username and password in Base64 and embeds it into its Authorization header. The encoding follows a set template. For instance, a client with the username “Bob” and password “thefarmer” will be embedded in the header as follows:

Note: The Authorization request header represents the username and password as Bob:thefarmer encoded in the Base64 format. The Basic keyword before the encoded text signifies that this request header is for basic authentication.

Once entered, this username and password are sent to the server, which verifies the user. This process is illustrated below:

Created with Fabric.js 3.6.6
The client sends its request

1 of 4

Created with Fabric.js 3.6.6
The server relays the error message to the client

2 of 4

Created with Fabric.js 3.6.6
The client forwards the same request along with its encoded credentials

3 of 4

Created with Fabric.js 3.6.6
The server verifies the request

4 of 4

The process is as expanded below:

  1. The client forwards a request to the server.

  2. The server can't authenticate the client, so it rejects the request and forwards the error message to the client through the WWW-Authenticate response header. Through this header, the client is prompted to enter their username and password.

  3. The client then relays the same request, this time with its encoded username and password along with the request in its Authorization header.

  4. The server verifies the user and allows the request to go through.

Points to Ponder

Question 2

Why do we encode the username and password in Base64?

Hide Answer

As a standard, the usernames and passwords in our HTTP headers should only contain ASCII characters. However, it’s possible that a client’s credential includes non-ASCII credentials, which we can’t embed directly into the header. To solve this issue, we encode the credentials in Base64, which generates a string containing ASCII characters that can be decoded when received by the server to obtain the actual username and password.

An example of this is the character , which may be used in a username or password. Because it isn’t an ASCII character, we can’t embed it in our header. However, its Base64 encoded format, 5pel, can be embedded into the header.

2 of 2

The advantages and disadvantages of HTTP basic authentication are as follows:

HTTP Basic Authentication Advantages and Disadvantages

Authentication Mechanism

Advantages

Disadvantages


HTTP basic authentication


  • Simplest of all authentication methods
  • The client's password will have to be forwarded on every API call, increasing its chances of being intercepted by an attacker
  • Overhead due to authenticating the client for every request
  • Credentials are encoded instead of being encrypted


This method has largely been discontinued in the API landscape because of the drawbacks mentioned above, so we turn to other authentication protocols.

API keys#

API keys deal with the shortcomings of HTTP basic authentication by replacing the encoded username and password with a generated string. API keys are uniquely generated by the API provider for every consumer/application developer to be used in their applications. It should be noted that API keys are merely strings that identify the application, and they require other security protocols for their secure transmission.

Note: API keys can’t authenticate end users making requests, just the application sending the request. For this purpose, it’s used in tandem with other protocols to implement authentication.

There are various ways in which an application might generate API keys. Some may generate random strings, further encode them, and finally pad with random characters in between. Other APIs increase the number of bits that represent each API key, which reduces both its predictability and increases the number of keys that can be given to applications. No matter what method is used, the goal is to provide unique and unguessable keys.

The following is an example of what an API key may look like:

With API key authentication, the application forwards its assigned API key in the header of its request. When the server receives the said request, it looks up the API key in its database in hopes of verifying the application. An example of API key generation is shown below:

Created with Fabric.js 3.6.6
The application sends a request to generate its API key

1 of 4

Created with Fabric.js 3.6.6
The server provides the application with its API key

2 of 4

Created with Fabric.js 3.6.6
The application sends an endpoint request with its API key

3 of 4

Created with Fabric.js 3.6.6
The application processes the request after verifying the user

4 of 4

Utilizing API keys over HTTP basic authentication has many benefits:

  • Unlike HTTP basic authentication, API keys provide applications the option to have multiple keys per account.

  • API keys are deemed more convenient than their counterpart, which can be seen in their ability to refresh and regenerate tokens used as API keys.

  • Because the API is separate from the user’s username and password, any security breach will be limited to the API. Even if the attacker has a compromised key, they won’t have the user’s credentials.

  • API keys can be revoked if need be, for instance, if the keys are compromised.

It's essential to keep API keys a secret because if an attacker gains access to an API key, the server won't be able to differentiate it from the legitimate user.

The advantages and disadvantages of API keys are as follows:

API Keys Advantages and Disadvantages

Authentication Mechanism

Advantages

Disadvantages



API keys


  • Preferred for their simplicity
  • Multiple keys can be made from the same master account
  • Better security in comparison with HTTP basic authentication


  • Need another authorization protocol alongside them, or else attackers can gain access to API keys and subsequent permissions
  • Have to be sent with every request that requires user authentication


JSON Web Token (JWT)#

A JSON Web Token (JWT) is an open standard that’s a compact and self-sufficient method for safely transferring data between entities in the form of JSON objects. JWTs are a collection of encrypted strings denoting a header, a payload, and a signature that travel through HTTP requests. Unlike the previous protocols, tokens can be used for both authentication and authorization purposes because they carry information about the token's holder.

JWTs are commonplace in the API landscape, especially with regard to the security protocols we explored earlier in this lesson. An example of a decoded JWT's header is shown below:

A JWT Header

The header contains information about the hashing algorithm and the token type. In the case above, HS256 is the hashing algorithm, and the token type is JWT.

Payloads contain statements about the user the token is assigned to, such as its name, issuer, and expiration, among others:

A JWT Payload

Finally, JWTs additionally include a signature that verifies that the holder of the token is legitimate and that the message hasn't been altered in transmission. To generate the signature, we sign the encoded header, the payload, and a secret (exclusive to the entity generating the JWT) with a hashing algorithm mentioned in the header. The recipient of the JWT will recalculate and compare the two signatures to determine if it was altered during transmission.

An example of signature representation is given below:

A JWT Signature

Note: Note: The code above is encoded as strings using base64. The header and payload are separated by a period, .. The encoded representation of a token follows the [header].[payload].[signature] template, with the period splitting the header, payload, and signature segments.

The structure of encoded JWTs
The structure of encoded JWTs

Tokens are embedded with a time limit, after which they are rendered invalid, and a new token has to be generated by using refresh tokens or authenticating into the server again. The slides below illustrates the creation and usage of tokens:

Created with Fabric.js 3.6.6
The client sends a request for token generation

1 of 4

Created with Fabric.js 3.6.6
The token is generated and sent to the client

2 of 4

Created with Fabric.js 3.6.6
The client makes a request to the server

3 of 4

Created with Fabric.js 3.6.6
The server verifies the token and sends the requested data to the client

4 of 4

The process is as follows:

  1. The client sends an authenticate request to the server with their username and password using HTTP authentication. The application validates the request and then creates a token for the client. In the slides above, the username is exampleuser, while the password is password. A token is sent to the client after generation.

  2. The token is stored on the client side and is sent through the HTTP Authorization header to the server when requests are made. The Bearer keyword signifies that this authentication scheme is token based, similar to how the Basic keyword earlier signified how basic authentication was being used. This request can be interpreted as requesting access to the bearer of this token.

  3. On arrival of the request, the server verifies the token. On successful verification, the server sends an appropriate response back to the client. In the slides, a GET request is put for the client's username, which is returned after verification of the token and the request.

API keys and tokens may seem similar, but there are a few key differences:

  • API keys only serve to identify the client, whereas tokens carry more information with them, such as their source, the identifier, and other metadata. This extra information is helpful for authorization purposes.

  • Tokens are structured to contain a header and a payload. API keys are just generated strings.

The frameworks discussed in the upcoming lesson will explore the usage of tokens.

The pros and cons of the techniques we explored in this lesson are compiled in the table below:

Pros and Cons of Each Technique

Technique

Advantages

Disadvantages



HTTP basic authentication



  • Simplest of all authentication methods


  • The client's password will have to be forwarded on every API call, increasing its chances of being intercepted by an attacker
  • Overhead due to authenticating the client for every request
  • Credentials are encoded instead of being encrypted




API keys


  • Preferred for its simplicity
  • Multiple API keys can be made from the same master account
  • Better security in comparison with HTTP basic authentication



  • Need another authorization protocol alongside them, or else attackers can gain access to API keys and subsequent permissions
  • Have to be sent with every request that requires user authentication


JWTs

  • They’re scalable
  • Offer temporary access to specific resources
  • Widely used in the API landscape


  • Processing JWTs can cause overhead
  • Require understanding of cryptographic signatures

Before we wrap up, let's take a look at the use cases in which API keys and JWTs may be helpful. In the case of blocking unauthorized traffic to our API, keys should be used because they authenticate the applications making the request. API keys are also used in implementing rate limiting, which controls how many calls a specific application is allowed to an API. They can also be used to filter logs by the specific API key.

In cases where we need secure authorization, JWTs that are used as keys are unable to provide this. This is because JWTs have finer-grained controls as compared to a single key. In projects where we need to identify the end users, JWTs are also preferred because keys only identify the application, not the user making the request.

In this lesson, we've explored various authentication and authorization protocols and their respective advantages and disadvantages. Now, in the following lesson, let's examine how these protocols are incorporated in different frameworks popular in the API landscape to fulfill our API's security goals.

Cross-Origin Resource Sharing (CORS) in APIs

OAuth: The Authorization Framework